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REMARKS /ARGUMENTS 

Claims 1-19, 21-24, 91 and 92 are pending in the present application. Claims 1-19, 
21-24, 91 and 92 have been rejected. Claims 20 25-90 have been cancelled. No new matter 
has been added. Accordingly, claims 1-19, 21-24, 91 and 92 are now pending in the present 
application. 



Claim Rejections - 35 USC $103 

The standard for making an obviousness rejection is currently set forth in MPEP 
706.02Q): 

To establish a prima facie case of obviousness, three basic criteria must be 
met . First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of 
ordinary skill in the art, to modify the references or to combine reference 
teachings. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must teach or 
suggest all the claim limitations. The teaching or suggestion to make the 
claimed combination and the reasonable expectation of success must both 
be found in the prior art, and not based on applicant's disclosure. 
(emphasis and formatting added) MPEP § 2143, In re Vaeck, 947 F.2d 488, 20 
USPQ2d 1438 (Fed. Cir. 1991) 

The initial burden is on the examiner to provide some suggestion of the 
desirability of doing what the inventor has done. "To support the conclusion 
that the claimed invention is directed to obvious subject matter, either the 
references must expressly or impliedly suggest the claimed invention or the 
examiner must present a convincing line of reasoning as to why the artisan 
would have found the claimed invention to have been obvious in light of the 
teachings of the references." Ex parte Clapp, 227 USPQ 972, 973 (Bd. Pat. 
App. & Inter. 1985). (emphasis added). 

See also, KSR International Co. v. Teleflex Inc., No. 04-1350, 550 U.S. __ (2007). 

As noted above, the PTO has the burden of establishing a prima facie case of 
obviousness under 35 USC §103. The Patent Office must show that some reason to 
combine the elements with some rational underpinning that would lead an individual of 
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ordinary skill in the art to combine the relevant teachings of the references. KSR 
International Co. v. Teleflex Inc., No. 04-1350, 550 U.S. __ (2007); In re Fine, 837 F.2d 1071, 
1074 (Fed. Cir. 1988). Therefore, a combination of relevant teachings alone is insufficient 
grounds to establish obviousness, absent some reason for one of ordinary skill in the art to 
do so. Fine at 1075. In this case, the Examiner has not pointed to any cogent, supportable 
reason that would lead an artisan of ordinary skill in the art to come up with the claimed 
invention. 

Moreover, as is further discussed below, none of the references, alone or in 
combination, teaches the unique features called for in the claims. It is impermissible 
hindsight reasoning to pick a feature here and there from among the references to 
construct a hypothetical combination which obviates the claims. 

It is impermissible, however, simply to engage in a hindsight reconstruction 
of the claimed invention, using the applicant's structure as a template and 
selecting elements from references to fill the gaps, [citation omitted] 

In re Gordon, 18 USPQ.2d 1885, 1888 (Fed. Cir. 1991). 

A large number of devices may exist in the prior art where, if the prior art be 
disregarded as to its content, purpose, mode of operation and general context, the several 
elements claimed by the applicant, if taken individually, may be disclosed. However, the 
important thing to recognize is that the reason for combining these elements in any way to 
meet Applicants' claims only becomes obvious, if at all, when considered from hindsight in 
the light of the application disclosure. The Federal Circuit has stressed that the 
"decisionmaker must step backward in time and into the shoes worn by a person having 
ordinary skill in the art when the invention was unknown and just before it was made." 
Panduit Corp. v. Dennison Mfg. Co., 810 F.2d 1561, 1566 (Fed. Cir. 1987). To do otherwise 
would be to apply hindsight reconstruction, which has been strongly discouraged by the 
Federal Circuit. Id. at 1568. 

To imbue one of ordinary skill in the art with knowledge of the 
invention in suit, when no prior art reference or references of record convey 
or suggest that knowledge, is to fall victim to the insidious effect of a 
hindsight syndrome wherein that which only the inventor taught is used 
against its teacher. 
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W.L. Gore & Assoc. v. Garlock, Inc., 721 F.2d 1540, 1553 (Fed. Cir. 

1983). 

Therefore, without some reason in the references to combine the cited prior art 
teachings, with some rational underpinnings for such a reason, the Examiner's conclusory 
statements in support of the alleged combination fail to establish a prima facie case for 
obviousness. See, KSR International Co. v. Teleflex Inc., No. 04-1350, 550 U.S. __ (2007) 
(obviousness determination requires looking at "whether there was an apparent reason to 
combine the known elements in the fashion claimed...", citing In re Kahn, 441 F.3d 977, 988 
(CA Fed. 2006) ("[R] ejections on obviousness grounds cannot be sustained by mere 
conclusory statements; instead, there must be some articulated reasoning with some 
rational underpinning to support the legal conclusion of obviousness," KSR at 14). 



a. Claims 1, 3-5, 10-12, 14-17, 22-24 and 91-92 were rejected under 35 
U.S.C.§ 103(a) as being unpatentable over Drexter (U.S. 2002/0046248 Al) in view of 
Meier et al. (U.S. 6,058,393). 

The Applicant respectfully traverses the rejection of independent claim 1 as being 
unpatentable over Drexter (U.S. 2002/0046248 Al) in view of Meier et al. (U.S. 6,058,393) 
as emphasized by the recited claim elements set forth below: 

Independent Claim 1 recites A method for converting messaging data 
into a relation table format in a database system, the messaging data being 
within a messaging system, the method comprising the steps of: 

(a) providing a plurality of table formatting specifications; 

(b) utilizing the plurality of table formatting specifications to 
automatically build and store a table function in the database system; and 

(c) invoking the table function from within the database system 
through a single database language statement, the table function 

(cl) invoking at least one messaging function within the 
database system to access the messaging data; 

(c2) converting the messaging data into relational table 
format according to the plurality of table formatting specifications, and 
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(c3) directly populating a relational table within the 
database system with the converted messaging data. (Emphasis added.) 

Drexter discloses a system that facilitates the transfer of data from an email message 
or the like to records, tables, and/or fields of an electronic database. In an illustrative 
embodiment, an email message and a number of database fields are identified. Certain data 
from the email message are associated with one or more of records, tables, and/or fields of 
the database. With this association, the data in the email message may be automatically or 
manually parsed and saved to the associated records, tables, and/or fields of the database. 
However, as admitted by the Examiner, Drexter does not distinctly disclose storing a table 
function in the database system and invoking the table function from within the database 
through a single database language statement. Consequently, the Drexter reference does 
not teach every element of the recited independent claim 1. 

The Examiner proposes to combine the Drexter reference with the Meier reference 
to cure Drexter's above-delineated defect. Meier discloses a dynamic connection for 
distributed applications that need to locate application development tools, including but 
not limited to debuggers, trace collection tools, compilers, etc.) which may be running on 
different machines, and to send the tools messages. The program requesting debugging 
service (i.e., a debugger client) sends, to a tool locator, criteria which specifies the 
properties of a desired debugger. The tool locator maintains a registry of all tools, e.g. 
debuggers, and their properties, which remain active within the network by receiving tool 
registration information from each tool as it is started on any machine within the network. 
When a message is received by the tool locator from a debugger client specifying the 
criteria of a desired debugger, the tool locator searches its registry and returns a list of 
debuggers matching the specified properties along with a communication endpoint address 
that can be used to establish a connection with a debugger meeting the criteria. The 
debugger client then sends a message, using the established connection, to the desired 
debugger requesting debugging services on behalf of the debugger client or another 
program. 
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The Examiner asserts that Meier teaches "...invoking the table function/rom within 
the database system through a single database language statement..." at col. 2 line 33 
through col. 3, line 42, which is reproduced herein below: 

The technology of running external programs on the server side of a Relational 
Database Management System (RDBMS) has been developed in the past few years. For 
example, DB2.TM./Common-Server for AIX.TM./6000 (DB2.TM./CS) supports external 
programs. External programs are written by the application developer in a host 3GL 
language such as C and C++. They could be invoked by the RDBMS in one of two forms: (1) as 
a subprogram running inside of the server's "address space" (also referred to as "process"), 
or (2) as a stand-alone application running on the server machine. The former is usually 
referred to as User-Defined Functions (UDF), and the latter is referred to as Stored 
Procedures. 



A stored procedure allows the application developer to break a database application 
program into a client part and a server part. A stored procedure is a precompiled program 
that is stored at the server site and invoked from the client. The server part can issue SQL 
language request while running on the same machine as the RDBMS server such as a 
DB2.TM./CS server. Results from the execution of the stored procedure can be passed back 
to the client part which is usually running on a different machine. In many applications, this 
can greatly improve the performance of the database application. Stored procedures reduce 
the network traffic between the client and the server. Other advantages include concealing a 
variety of system-specific and/or database-specific details from the user, thereby providing 
a greater degree of data independence; sharing a stored procedure by many clients; and 
providing enhanced security by authorizing a given user to invoke a given procedure but not 
to operate directly on the data accessed by that procedure. 

In addition, the following described invention is also applicable to triggers. A trigger 
allows a user to associate certain SQL operations with a certain event A trigger is a 
procedure that is to be invoked, by the database management system, when a specific 
condition occurs. For example, a trigger could be invoked to check the range value of 
employees' salaries whenever an SQL update is made to an employee/salary table to 
ensure that no salary goes above a certain amount More specifically, an external 
trigger is a trigger than runs externally from the system software, i.e., a DBMS. 

UDF (User-Defined Function) is, as its name implies, a function that takes in input and 
returns single value results. As a function, it must be embedded in an SQL expression. UDF is 
an innovative feature introduced in release 2 of the IBM DB2.TM./6000 relational database 
system. In addition, the new SQL3 standard provides a definition for user-defined functions. 
A user-defined function extends the functionality of the underlying DBMS (Data Base 
Management System) such as DB2.TM./CS by allowing users to define their own SQL 
functions implemented in a 3GL host language such as C and C++. Once created in the DBMS, 
UDFs can be invoked from any context where a SQL expression is expected or invoked from 
within any SQL expression as if they were built-in functions. 

In a practical implementation, UDF could be run under two kinds of environment. For better 
security, a "firewall" is created between the database engine run-time and the UDF run-time. 
This is normally achieved by running UDF code in a separate process which is different from 
the engine process. Such a UDF is called a fenced UDF. In contrast, for better performance, 
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UDF code is run in the same process as that of the database engine. Such a UDF is called an 
un-fenced UDF. 

There are two components associated with a UDF: the specification component and the 
realization component. The former is specified by the create function SQL statement and 
maintained by the DBMS. The latter is specified by code written in a host language, prepared 
using the host language compiler and linkage editor, and maintained by the operating 
system. Different UDFs can share the same implementation. In other words, one realization 
component can be associated with more than one specification component. One situation 
where this can occur is when two UDFs have the same functionality but different runtime 
environments: one runs in a fenced mode, and the other runs in an unfenced mode. 

It is unclear to Applicant where the Examiner is construing Meier as teaching or 
suggesting the limitation "invoking the table function from within the database system 
through a single database language statement" as recited in claim 1. In fact, Meier teaches 
away from this limitation. Meier discloses a trigger that allows a user to associate certain 
SQL operations with a certain event. However, Meier describes the implementation of an 
"external trigger" which is a trigger that runs externally from the system software, i.e., a 
DBMS. This is clearly distinguishable from "invoking the table function from within the 
database system through a single database language statement" as recited in independent 
claim 1. Specifically, the "external trigger" disclosed by Meier (which runs externally from 
the DBMS] cannot be construed as teaching or suggesting the "invoking the table function 
from within the database system through a single database language statement" in 
conjunction with the recited elements of claim 1 since the table function is invoked "from 
within the database". 

Consequently, since Meier does not teach or suggest the limitation "...invoking the 
table function/ro/n within the database system through a single database language 
statement" in conjunction with the recited elements of claim land in fact, teaches away 
from this limitation, the Examiner's proposed combination of references do not teach or 
suggest ah claim limitations. Accordingly the rejection of independent claim 1 as being 
unpatentable over Drexter (U.S. 2002/0046248 Al) in view of Meier et al. (U.S. 6,058,393) 
under 35 U.S.C. §103(a) should be withdrawn. 

Claims 3-5, 10-12, 14-17, 22-24 and 91-92 depend from independent claim 1 and 
inherit all of it's limitations. Therefore, claims 3-5, 10-12, 14-17, 22-24 and 91-92 are also 
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patentably distinct in light of Drexter (U.S. 2002/0046248 Al) in view of Meier et al. (U.S. 
6,058,393) and the rejections of claims 3-5, 10-12, 14-17, 22-24 and 91-92 under 35 U.S.C. 
§103 (a) ought to now be withdrawn. 

b. Claims 6-9 were rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Drexter (U.S. 2002/0046248 Al) in view of Meier et al. (U.S. 6,058,393) as 
applied to claims 1-5, 10-12, 14-17 and 22-24 above and in further view of Demers et 
al. (US 5,870,761). 

Claims 6-9 depend from independent claim 1 and inherit all of it's limitations. As 
discussed above, the independent parent claim has not been rendered unpatentable by the 
Examiner's proposed combination of reference since they fail to provide, among other 
things, the limitation "...invoking the table function from within the database system 
through a single database language statement...". 

Insofar as the Demers reference does not overcome the shortcomings of the 
Examiner's proposed combination of references, claims 6-9 are also patentably distinct in 
light of Drexter (U.S. 2002/0046248 Al] in view of Meier et al. (U.S. 6,058,393) as applied 
to claims 1-5, 10-12, 14-17 and 22-24 above and in further view of Demers et al. (US 
5,870,761] and the rejection of claims 6-9 under 35 U.S.C. §103(a) ought to now be 
withdrawn. 

c. Claim 13 is rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Drexter (U.S. 2002/0046248 Al) in view of Meier et al. (U.S. 6,058,393) as applied to 
claims 1-5, 10-12, 14-17, 22-24, 26-31, 36-38, 40-43, 48-50, 52-58, 64-65 and 67-90 
above and in further view of Huth et al. (US 6,704,742). 

Claim 13 depends from independent claim 1 and inherit all of it's limitations. As 
discussed above, the independent parent claim has not been rendered unpatentable by the 
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Examiner's proposed combination of reference since they fail to provide, among other 
things, the limitation "...invoking the table function/rom within the database system 
through a single database language statement...". 

Insofar as the Huth reference does not overcome the shortcomings of the Examiner's 
proposed combination of references, claim 13 is also patentably distinct in light of Drexter 
(U.S. 2002/0046248 Al] in view of Meier et al. (U.S. 6,058,393) as applied to claims 1-5, 10- 
12, 14-17, 22-24, 26-31, 36-38, 40-43, 48-50, 52-58, 64-65 and 67-90 above and in further 
view of Huth et al. (US 6,704,742] and the rejection of claim 13 under 35 U.S.C. §103(a) 
ought to now be withdrawn. 

d. Claims 18, 19 and 21 are rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Drexter (U.S. 2002/0046248 Al) in view of Meier et al. (U.S. 
6,058,393) as applied to claims 1-5, 10-12, 14-17, 22-24, 26-31, 36-38, 40-43, 48-50, 
52-58, 64-65 and 67-90 above and in further view of Poskanzer (US 6,658,426). 

Claims 18, 19 and 21 depend from independent claim 1 and inherit all of it's 
limitations. As discussed above, the independent parent claim has not been rendered 
unpatentable by the Examiner's proposed combination of reference since they fail to 
provide, among other things, the limitation "...invoking the table function/rom within the 
database system through a single database language statement...". 

Insofar as the Paskanzer reference does not overcome the shortcomings of the 
Examiner's proposed combination of references, claims 18, 19 and 21 are also patentably 
distinct in light of Drexter (U.S. 2002/0046248 Al) in view of Meier et al. (U.S. 6,058,393) as 
applied to claims 1-5, 10-12, 14-17, 22-24, 26-31, 36-38, 40-43, 48-50, 52-58, 64-65 and 
67-90 above and in further view of Poskanzer (6,658,426) and the rejection of claim claims 
18, 19 and 21 under 35 U.S.C. §103(a) ought to now be withdrawn. 



15 



Attorney Docket No.: SVL920010074US1/2304P 



CONCLUSION 

Applicants' attorney believes this application is in condition for allowance. Should 
any unresolved issues remain, Examiner is invited to call Applicants' attorney at the 
telephone number indicated below. 

It is believed that all of the pending Claims have been addressed. However, the 
absence of a reply to a specific rejection, issue or comment does not signify agreement with 
or concession of that rejection, issue or comment. In addition, because the arguments 
made above may not be exhaustive, there may be reasons for patentability of any or all 
pending Claims (or other Claims) that have not been expressed. Finally, nothing in this 
paper should be construed as an intent to concede any issue with regard to any Claim, 
except as specifically stated in this paper, and the amendment of any Claim does not 
necessarily signify concession of unpatentability of the Claim prior to its amendment. 

Respectfully submitted, 

July 31, 2008 /Joseph A. Sawyer, J r. / 

Joseph A. Sawyer, Jr. 
Reg. No. 30,801 

Customer Number 45728 

(650) 493-4540 
(650) 493-4549 
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